home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / iesg / 92_11_20 < prev    next >
Text File  |  1993-02-04  |  13KB  |  356 lines
  1.  
  2.                     IETF STEERING GROUP (IESG)
  3.  
  4.                   REPORT FROM THE IETF MEETING
  5.  
  6.                        November 20th, 1992
  7.  
  8.          Reported by:  Greg Vaudreuil, IESG Secretary
  9.  
  10.  
  11. This report contains IESG meeting notes, positions and action items.
  12.  
  13. These minutes were compiled by the IETF Secretariat which is supported
  14. by the National Science Foundation under Grant No. NCR 8820945.
  15.  
  16. For more information please contact the IESG Secretary.
  17.  
  18. ATTENDEES
  19. ---------
  20.  
  21.     Almquist, Philip / Consultant
  22.     Borman, David / Cray Research
  23.     Crocker, Dave / TBO
  24.     Crocker, Steve / TIS
  25.     Coya, Steve / CNRI
  26.     Gross, Philip / ANS
  27.     Hinden, Robert / SUN
  28.     Hobby, Russ / UC-DAVIS
  29.     Huizer, Erik / SURFnet
  30.     Knowles, Stev / FTP Software
  31.     Reynolds, Joyce / ISI
  32.     Piscitello, Dave/ Bellcore
  33.     Stockman, Bernard / SUNET/NORDUnet
  34.     Vaudreuil, Greg / CNRI
  35.  
  36.  Regrets
  37.     Davin, Chuck / Bellcore
  38.  
  39. IAB ATTENDEES
  40.  
  41.     Braden, Robert / ISI
  42.     Cerf, Vinton / CNRI
  43.     Chapin, Lyman / BBN
  44.     Huitema, Christian / INRIA
  45.     Kent/ Stephen / BBN
  46.     Lauch, Anthony / DEC
  47.     Leiner, Barry / NASA
  48.     Postel, Jon / ISI
  49.   
  50.  Regrets
  51.     Braun, Hans-Werner / SDSC
  52.     Lynch, Daniel / Interop
  53.  
  54.  
  55. AGENDA
  56. ------
  57.  
  58. 1) Protocol Actions
  59.  
  60.  o Telnet Environment Option
  61.  o Telnet Authentication Options
  62.      - SPX
  63.      - Kerberos V4
  64.  o String Representation of Distinguished Names
  65.  o Network Time Protocol
  66.  o Common OSI Management in the Internet (CMOT)
  67.  
  68. 2) IETF Progress Report
  69.  
  70. 3) IETF Re-organization
  71.  
  72. 4) New IP Review
  73.  
  74. MINUTES
  75. -------
  76.  
  77. 1) Protocol Actions
  78.  
  79.    The IESG reviewed the following protocol actions under the new and
  80.    evolving standards process continuing in the POSISED Working Group.
  81.  
  82.  o Telnet Environment Option
  83.  
  84.    The IESG reviewed the Telnet Environment option and approved it for
  85.    Proposed Standard.  This option was previously sent to the IAB and
  86.    was sent back to Working Group for revision.  The Working Group has
  87.    specified an initial set of Operating System independent variables
  88.    and provided a mechanism for session specific variables.
  89.  
  90. ACTION: Vaudreuil -- Send an IESG approval for the Telnet
  91. Authentication Option to the RFC Editor and the IETF.
  92.  
  93.  o Telnet Authentication Protocols
  94.     - Telnet Authentication
  95.     - SPX
  96.     - Kerberos V4
  97.  
  98.    The Telnet Working Group has several documents for telnet
  99.    Authentication.  These documents are complete but are expected to be
  100.    obsolete shortly by a more comprehensive set of
  101.    authentication/encryption documents.  The Working Group requested
  102.    Experimental status for the current set. In the absence of a
  103.    Prototype designation, the IESG agreed and approved the documents
  104.    for Experimental status.
  105.  
  106. ACTION: Vaudreuil -- Request that the RFC Editor publish the Telnet
  107. Authentication documents as Experimental Protocols.
  108.  
  109.  o String Representation of Distinguished Names
  110.  
  111.    The IESG approved the string representation of distinguished names
  112.    document as a Proposed Standard.  This document along with the User
  113.    Friendly Naming document earlier approved as experimental by the
  114.    IESG was previously submitted to the IAB as a Proposed Standard.
  115.    This document is narrower in scope and represents one of
  116.    several possible human-readable representations suitable for email
  117.    or business card exchange.  Additional comments were received by
  118.    Steve Kent but the IESG left the decision on whether to incorporate
  119.    these changes to the current version or the Draft Standard version
  120.    up to the author. 
  121.  
  122. ACTION: After the author either makes additional edits or indicates
  123. that current document is complete, send an IESG Approval for the String
  124. Representation of Distinguished Name document to the RFC Editor and the
  125. IETF.
  126.  
  127.  
  128.  o Network Time Protocol
  129.  
  130.    After significant discussion, the IESG concluded that there was
  131.    inadequate information to elevate the Network Time Protocol to Draft
  132.    Standard.  While there are two implementations for differing
  133.    platforms, it is not clear that it is possible to implement an
  134.    independent interoperable implementation from RFC1113.  NTP has not
  135.    been subject to a Working Group review but was reviewed by an
  136.    independent group of IETF experts before going to Proposed
  137.    Standard.  The IESG will consult again with this group and if
  138.    necessary form a Working Group.
  139.  
  140. ACTION: Hobby -- Consult with the original panel of reviewers of the
  141. NTP specification and determine if there is adequate experience to
  142. elevate NTP to Draft Standard.
  143.  
  144.  o Common OSI Management in the Internet (CMOT)
  145.  
  146.    The CMOT protocol has been a Proposed Standard for two years and
  147.    there is no indication that there is, or will be in the near term,
  148.    the necessary level of implementation or experience to elevate
  149.    the protocol to Draft Standard.  The IESG approved moving CMOT off
  150.    the standards track to Historic.
  151.  
  152. ACTION: Vaudreuil -- Notify the IETF that the IESG has moved CMOT off
  153. the standards track.
  154.  
  155.  
  156. 2) IETF Progress Report
  157.  
  158.    Several protocols which were in need of revision or were long
  159.    expected to be submitted to the IESG were completed at the
  160.    Washington IETF Meeting.
  161.  
  162.  o SMTP Extensions
  163.  
  164.    The impasse on the documentation style and all technical issues were
  165.    resolved.  New documents should be submitted to the Internet Drafts
  166.    and IESG shortly.
  167.  
  168.  o IDENT
  169.  
  170.    The IDENT specification with character set changes recommended by
  171.    the IESG was reviewed and accepted by the Working Group.
  172.  
  173.  o Dynamic Host Configuration
  174.  
  175.    The specifications for the protocol and options were reviewed and
  176.    accepted by the Working Group.
  177.  
  178.  o Privacy Enhanced Mail
  179.  
  180.    PEM is now finished and will be submitted to the IESG within a
  181.    week.  Integration with MIME has begun and this work is intended to
  182.    progress independently.
  183.  
  184. 3) IETF Re-Organization
  185.  
  186.    The IESG discussed specific points of the POISED proposal for
  187.    re-organization of the IETF/IESG/IAB relationship.
  188.  
  189.  o IESG Selection.
  190.  
  191.    The proposal for selection of IESG members was a discussed.  Two
  192.    specific concerns were raised, attention to the cooperative spirit of
  193.    the IESG in selection new members and continuity in the technical
  194.    management.   The IESG affirmed the proposals for the nomination
  195.    committee to seek guidance from the IESG in selecting new members.
  196.    Further, the IESG decided that IESG positions should be put up for
  197.    re-affirmation, not individual members.  This is especially
  198.    important in large area with co-area directors.  It was felt that
  199.    only one of the Directors should be put up for re-affirmation at a
  200.    time.
  201.  
  202.    The IESG periodically reviews its operations and re-organizes areas
  203.    to reflect new priorities and workloads.  The integration of OSI
  204.    Working Groups into other IESG Areas is one such re-organization.
  205.    It was agreed that the IESG should remain free to pursue such
  206.    re-organization with the understanding that any new IESG positions
  207.    will be subject to the normal nomination process.
  208.  
  209.    Five of the six members needed to be re-affirmed volunteered, Dave
  210.    Piscitello, Dave Crocker, Dave Borman, Stev Knowles, and Phill
  211.    Gross.
  212.  
  213.  o IESG Workload
  214.  
  215.    The IESG and IAB agreed to begin operating under the current
  216.    proposal for IESG final approval of standards.  This will entail a
  217.    greater workload on the IESG with no immediate increase in either
  218.    IESG membership or secretariat support.  The formation of
  219.    directorates, bodies of experts in a specific area who can aid the
  220.    Area Director in the review of protocols and mentoring of Working
  221.    Groups are now more critical.  IESG meetings will need to become
  222.    more focused on protocol standardization and in-depth review of
  223.    architectural issues.  The IESG discussed off-loading the IETF
  224.    chairman by assigning responsibility for meeting planning, and the
  225.    technical presentation program to the Executive Director.  To
  226.    accomplish this, the IESG discussed the creation of a "facilitator"
  227.    a non-technical participant who can manage the agenda and steer the
  228.    group toward consensus.  Steve Coya as the Executive Director of the
  229.    IETF was named as the obvious
  230.    choice.
  231.  
  232.  o Process Changes
  233.  
  234.    The Poised proposal will result in many changes.  Several of these
  235.    were accepted by the IESG and IAB for immediate implementation.
  236.  
  237.    - The IESG will now make decisions on standards track protocols
  238.    starting immediately.  Protocols on the IAB's plate will continue
  239.    through the previous process.
  240.  
  241.    - RFC 1310 will be updated.  Steve Coya was assigned the task of
  242.    serving as editor for the IESG update of this document.
  243.  
  244. ACTION: Coya, Dcrocker -- Revise RFC 1310 to reflect the changes in the
  245. IESG/IAB structure.  It is hoped that a solid cut can be made by the
  246. December 10th ISOC Trustees meeting.
  247.  
  248.    - The IESG, i.e., Steve Coya, now has responsibility for reporting
  249.    standardization progress in the Internet Monthly Report and the
  250.    Internet Society News.
  251.  
  252.    - Area Directors need explicit guidelines for Working Group Chairman
  253.    and Area Directorates.  A revised Working Group guidelines incorporating
  254.    the information from Erik Huizer's OSI area guidelines will be produced.
  255.  
  256. ACTION: Huizer -- Revise the Guidelines to Working Group chairman to
  257. offer more explicit guidance and to define the role of the IESG Area
  258. Director in terms of Working Group management.
  259.  
  260.  
  261.    - The IESG needs to write a new charter for itself under the IAB.
  262.    The IAB needs to revise its charter to reflect new duties.
  263.  
  264.  o Outstanding Concerns
  265.  
  266.    With the IAB, the IESG took an round-robin survey to identify the
  267.    outstanding areas of concern with the Poised proposal.  The
  268.    following concerns were identified.
  269.  
  270.    The professionalism of the IAB/IESG is valuable and must be
  271.    protected. The nominating committed must be able to work in
  272.    confidence in considering personnel.  Fear of recall petitions may
  273.    make members reluctant to tackle hard problems.
  274.  
  275.    IESG members serve as technical members but are responsible for
  276.    management of the IETF work and need to be selected with an eye to
  277.    both roles.
  278.  
  279.    The IESG relies upon a close collegial relationship for coordinating
  280.    technical work and the nominating committee needs the input of
  281.    existing members to determine if new members can work within the
  282.    IESG.  Further, the replacement of 1/2 of the IESG per vote must be
  283.    structured in such a way that the area continuity can be maintained,
  284.    likely by placing only one of co-area directors up for re-nomination
  285.    per period.
  286.  
  287.    IESG workload will increase.  In the short term progress is likely
  288.    to get slower, not faster.
  289.  
  290.    The role of the IAB as appeals board needs to be better defined. The
  291.    process framework needs to be legally defensible but not be
  292.    over-defined to the point of OSI-fication.
  293.  
  294. 4) New IP Review
  295.  
  296.    At this IETF meeting the several proposals for the next IP were
  297.    presented and discussed.  The field of choices appears to have
  298.    narrowed by attrition to two, CLNP and SIP/IPAE.  There were many
  299.    viewpoints explored on the wisdom of choosing a single choice with
  300.    the a general consensus that it is better for the IESG/IAB to lead
  301.    towards a choice by specifying increasingly higher hurdles and
  302.    setting firm criteria for the proposals than to pick a single
  303.    protocol.
  304.  
  305.    This view towards community decision making results from an
  306.    understanding that any meaningful decision by the IAB/IESG would
  307.    have to be made early, before a substantial investment in
  308.    implementation, and hence before firm experience is gathered.
  309.    Experience and the pressure of competition will result in stronger
  310.    proposals which reflect implementation and transition experience.
  311.    Strong dissenters from this view charge that the costs of parallel
  312.    tracks are too great and that a decision, even if it is not the best
  313.    of the contenders will better conserve resources for faster
  314.    deployment.
  315.  
  316.    The IESG discussed and came to the conclusion that a decision can be
  317.    made, but only if there is community consensus that a decision needs
  318.    to be made.
  319.  
  320. ACTION: Knowles, Almquist -- Write a draft statement to be sent to the
  321. IETF mailing list inquiring about the desire to make a decision on the
  322. next IP.
  323.  
  324.  
  325. Appendix -- Action Items
  326.  
  327. ACTION: Vaudreuil -- Send an IESG approval for the Telnet
  328. Authentication Option to the RFC Editor and the IETF.
  329.  
  330. ACTION: Vaudreuil -- Request that the RFC Editor publish the Telnet
  331. Authentication documents as Experimental Protocols.
  332.  
  333. ACTION: After the author either makes additional edits or indicates
  334. that current document is complete, send an IESG Approval for the String
  335. Representation of Distinguished Name document to the RFC Editor and the
  336. IETF.
  337.  
  338. ACTION: Hobby -- Consult with the original panel of reviewers of the
  339. NTP specification and determine if there is adequate experience to
  340. elevate NTP to Draft Standard.
  341.  
  342. ACTION: Vaudreuil -- Notify the IETF that the IESG has moved CMOT off
  343. the standards track.
  344.  
  345. ACTION: Coya, Dcrocker -- Revise RFC 1310 to reflect the changes in the
  346. IESG/IAB structure.  It is hoped that a solid cut can be made by the
  347. December 10th ISOC Trustees meeting.
  348.  
  349. ACTION: Knowles, Almquist -- Write a draft statement to be sent to the
  350. IETF mailing list inquiring about the desire to make a decision on the
  351. next IP.
  352.  
  353. ACTION: Huizer -- Revise the Guidelines to Working Group chairman to
  354. offer more explicit guidance and to define the role of the IESG Area
  355. Director in terms of Working Group management.
  356.